📚 Week 5 · Unit IV · Lecture 15
VCS vs DVCS;
The Local Repository

Unit IV kickoff: A deep dive into the architectural shift from Centralized to Distributed Version Control, understanding the Local Repository, and exploring the Multiple Repositories Model.

Dr. Mohsin Furkh DarSchool of Computer Sciences
DateTue, 07 Jul 2026 · 9:00 – 10:00 AM
ProgrammeBTech CSE – Summer Semester
Today's Agenda
1
Welcome to Unit IV — Advanced Version Control
2
Deep Dive: CVCS vs. DVCS Architecture
3
The Concept of the Local Repository
4
The Three-Tree Architecture of Git
5
The Multiple Repositories Model
6
Decentralized Workflows & Remotes
Unit IV Kickoff
Welcome to Unit IV
📚
Unit III Recap: We covered the DevOps Toolchain, an introduction to CI/CD pipelines, and the history of SCM — tracing the evolution from local files to SVN to Git. We saw the high-level commands for each.
🎯
Unit IV Focus: Now we go deep into Distributed Version Control Systems (DVCS) — specifically Git. We will cover the architectural models, resetting environments, advanced branching strategies, and how code merges integrate into the DevOps workflow.
Why Focus on DVCS?
  • It is the absolute standard in the industry (>95% adoption).
  • Its architecture is fundamentally different from traditional systems.
  • It is the enabler for modern CI/CD pipelines.
Today's Core Question
  • What actually makes a system "distributed"?
  • How does having a repository on your local machine change the way you write software?
Architecture Comparison
VCS (Centralized) vs DVCS (Distributed)

The fundamental difference lies in where the history lives. Let's compare the topologies.

Centralized (SVN)
  • One Server: Holds the full history (version database).
  • Clients: Only hold a snapshot of a specific version (Working Copy).
  • Commit: Pushes a delta directly to the central server.
  • Failure Mode: If the server disk dies, all history is gone.
Distributed (Git)
  • Every Node: Is a full server. It holds the complete history database.
  • Clients: Hold the full repo and a working copy.
  • Commit: Saves locally. Push: Syncs repos.
  • Failure Mode: If the central server dies, just copy any client's repo back up.
🛡️
No Single Point of Failure: In DVCS, every single developer's laptop acts as a full, automated backup of the entire project history.
Core Concept
The Local Repository
🏠
In a DVCS like Git, the Local Repository is a hidden folder (.git/) on your hard drive. It is a complete, self-contained database containing every commit, every branch, and every tag ever created in the project.
⚡
Instant Operations
Because the database is local, commands like git log (view history) or git checkout (switch branches) do not require a network request. They execute in milliseconds.
✈️
Offline Work
You can commit code, create branches, and merge features while completely offline. You only need the internet when you want to push or pull from others.
🧪
Safe Experimentation
Because your commits are local, you can commit broken code, experiment, and rewrite your own history without breaking the build for anyone else.
Git Architecture
The Three-Tree Architecture

To manage the local repository, Git uses a three-stage architecture. Understanding these "three trees" is the key to mastering Git.

📁
Working Directory
(Modified)
→
git add
🛠️
Staging Area (Index)
(Staged)
→
git commit
🗄️
Local Repository
(Committed)
1. Working Directory

The actual files you see and edit on your computer. It's a single checkout of one version of the project.

2. Staging Area (Index)

A preparatory area. You "stage" specific changes here to build exactly what you want your next commit to look like.

3. Local Repository (.git directory)

The database where Git permanently stores the metadata and object database for the committed snapshots.

Deep Dive
Why Have a Staging Area?

SVN and Mercurial do not have a staging area. If you type svn commit, it commits every changed file. Why did Git add this extra step?

The staging area allows you to craft logical commits. You can modify 10 files, but stage and commit them as 3 separate, well-documented features.

🧩
Partial Commits
You edit login.js and footer.css at the same time. They are unrelated. The staging area lets you commit login.js first as "Fix login", then footer.css as "Update styling".
🔍
Review Before Commit
Running git diff --staged lets you see exactly what is about to be permanently saved to the repository, acting as a final sanity check.
✂️
Line-by-Line Staging
Advanced feature: Git allows you to stage parts of a file (hunks) while leaving other edits in the same file unstaged (git add -p).
Network Architecture
The Multiple Repositories Model

Because every clone is a full repository, DVCS inherently supports a Multiple Repositories Model. There is no technical "master" server — only a social one.

Peer-to-Peer Concept
  • In Git, your repository is equal to my repository.
  • I can pull directly from your laptop to my laptop (if on the same network).
  • There is no hierarchy built into the Git protocol itself.
The Hub-and-Spoke Reality
  • While Git is peer-to-peer, human teams need a central source of truth.
  • We choose to designate one repository (usually on GitHub/GitLab) as the "Blessed Repository".
  • Everyone pushes to and pulls from this central hub.
🌐
Remotes: A "remote" is simply a bookmark to another repository. When you clone from GitHub, Git automatically creates a remote named origin pointing to that URL. origin is just a convention, not a magical technical keyword.
Multiple Repositories
The Integration-Manager Workflow

The multiple repositories model allows for complex workflows. The most common in open-source (and enterprise via Pull Requests) is the Integration-Manager workflow.

Blessed Repo(origin/main)
Fork(Developer's Remote)
Clone(Local Repo)
Push(To Fork)
Pull Request(Ask to merge)
1
The Fork
A developer creates their own personal server-side copy (Fork) of the Blessed Repository.
2
Local Work
They clone their fork locally, commit changes, and push back to their personal fork.
3
The Pull Request (PR)
They ask the Integration Manager (or team) to pull the changes from their fork into the Blessed Repository.
4
Integration
The manager reviews the code. If approved, the changes are merged into the Blessed Repo, becoming the new truth.
Putting it Together
The Four-Stage File Lifecycle

Combining the Local Repository with the Multiple Repositories model, a code change moves through four distinct stages.

1️⃣
Working Directory
State: Untracked or Modified.
Action: You type code and save the file in your editor. The changes only exist on your hard drive.
2️⃣
Staging Area
State: Staged.
Command: git add
Action: You mark the changes to go into the next snapshot.
3️⃣
Local Repository
State: Committed.
Command: git commit
Action: Safely stored in your local .git/ database.
4️⃣
Remote Repository
State: Pushed / Shared.
Command: git push
Action: Uploaded to GitHub/GitLab for the team and CI/CD.
Commands
Syncing Local and Remote
# View connected remote repositories
git remote -v
# Output:
# origin https://github.com/team/project.git (fetch)
# origin https://github.com/team/project.git (push)

# FETCH: Download changes from remote, but DO NOT merge them into your files
git fetch origin

# MERGE: Combine the fetched changes into your current branch
git merge origin/main

# PULL: Fetch and Merge in a single step (the most common command)
git pull origin main

# PUSH: Upload your local commits to the remote repository
git push origin feature-branch
⚠️
Push Rejections: If someone else pushed to the remote branch while you were working offline, the server will reject your push. You must git pull their changes, merge them with yours locally, and then git push the combined result.
Advanced Models
Dictator and Lieutenants Workflow

Because DVCS allows unlimited repository topologies, massive projects (like the Linux kernel) use this hierarchical multi-repository model.

The Hierarchy
  • Dictator: (e.g., Linus Torvalds). Owns the "Blessed" repo. Only pulls from trusted Lieutenants.
  • Lieutenants: Sub-system maintainers. They review and pull code from standard developers.
  • Developers: Write code, push to their own forks, and ask Lieutenants to pull.
Why Use This?
  • Scales to thousands of developers.
  • The "Dictator" doesn't have to review 10,000 PRs — they only review the aggregated work from a few Lieutenants.
  • Only possible because every node is a fully functional repository.
Context
Why DVCS is the Engine of DevOps
🌿
Enables Feature Branches
Because branching is cheap and local, developers create a branch for every task. This isolates work until it's perfectly ready.
🤖
Isolates CI Triggers
When a dev pushes a feature branch to the remote, the CI server can run tests on just that branch. Broken code is caught before it ever reaches main.
🤝
Enables Code Review
The Multiple Repositories model birthed the Pull Request. Code review is now a mandatory, asynchronous gatekeeper in the DevOps pipeline.
📜
Everything as Code
Because DVCS handles branches so well, Ops teams now store Infrastructure (Terraform) and Pipelines (YAML) in Git, applying identical workflows to ops code.
Summary
Key Takeaways — Lecture 15

Today we broke down the architecture of Distributed Version Control, focusing on local repositories and multi-repo workflows.

01
DVCS ArchitectureEvery clone is a full repository containing the entire history. No single point of failure. Operations are extremely fast because they are local.
02
The Three TreesGit uses the Working Directory (modified), the Staging Area/Index (staged), and the Local Repository (committed).
03
The Staging AreaAllows developers to craft logical, partial commits from their working changes, reviewing code before permanently saving it.
04
Multiple Repositories ModelTechnically peer-to-peer, but practically used as a Hub-and-Spoke model. "Origin" is just the default name for the hub remote.
05
The 4-Stage LifecycleWorking Dir → (add) → Staging → (commit) → Local Repo → (push) → Remote Repo.
06
Next: Lecture 16Resetting the local environment, cancelling changes, and reverting commits. How to fix mistakes in Git.
🎯
Exam tip: Be able to draw and explain the Three Trees (Working, Staging, Local Repo). Understand the difference between git fetch (downloads data) and git pull (downloads AND merges). Know why the staging area exists.